In the area of land-line solutions and the use of the Internet, the most common solution for solving the discovery and integration of new services is through Universal Description, Discovery and Integration (UDDI). UDDI provides a browser and Application Program Interface (API) centric view of dealing with dynamic services. The browser method treats potential service users as always online. The API method also assumes always online and continuous high speeds for program to program communication. The UDDI method of host service registration is described by the following documents found on the www.uddi.org Internet web site: Version 2.0 Programmer's API Specification, Version 2.0 Data Structure Specification, Version 2.0 Replication Specification Version 2.0 Operator's Specification, Executive White Paper (version 1.0), Technical White Paper (version 1.0), Using WSDL in a UDDI Registry 1.05, Using WSCL in a UDDI Registry (1.02) and Providing a Taxonomy for Use in UDDI Version 2.
FIG. 1 describes a simplified view of the relationships depicted and expected in the UDDI specifications. In UDDI the business user 2 is the center of attention as they justify the presence of the service by paying for the service. Business users 2 are motivated to use and find services to solve real-world business problems. Business users 2 use marketplace web sites 4 and search portals 6 to find required web services. The UDDI service cloud 8 acts as a worldwide repository of service information 10 that is accessible in a distributed manner through a network like the Internet. Behind the service cloud are actually databases 10, perhaps using LDAP services or some other fast look-up technology to satisfy service requests. These databases 10 might be distributed around the globe and may communicate using a UDDI propagation technique as defined in the UDDI specification. Populating these databases 10 are technical users 14 that write software that includes UDDI protocols and practices 12. These programs register their service information in the large service registry system. This triangle relationship just described is the bases of the majority of the UDDI specification.
UDDI and other similar types of service registry definitions all define a central store where all services can be found if desired. The UDDI specifications describe ways to manipulate, change and replicate this information between databases in the UDDI cloud. Additionally the services are categorized into Taxonomies to further help with locating and identifying the service needed.
FIG. 2 is an illustration of the relationships between a service offering 16, a service listing 20 and a service user 18 in a UDDI environment This three-way relationship has its advantages for landline environments, but needs modification and extending for wireless environments. Essentially, a company, person or organization decides they want to create a public or semi-public service that should be made available to a wide audience of users. The service creator 16, or the eventually service provider 16, propagates the service information to a central registry of public services 20. In addition, a third party may develop the software, and each time it is purchased and installed a new service registry entry is created. Alternatively, a single company may created the service and also offer it to the public. Another possibility is that several companies may build a service and each run a similar version of the service.
Within the service registry 20 further propagation takes place so that the service information is distributed throughout the entire system of service registries 10. Essentially the act of publishing the service information once, allows for a “publish once access anywhere” design approach. This publishing can be done programmatically or through manual processes through the UDDI API definitions. Part of UDDI is a rich set of XML and SOAP-based commands that allow service providers to securely establish, modify and delete entries in the registry database 20.
The service listing 20 provides a source of new services for service users 18. Service users are typically web browser users, but could also be programs looking for services. This helps to support web crawlers that are building service listings and search portal information. Users typically start up web browsers to search for service information and perform searches until the information is found. This model is based on a request/response model, or a pull architecture. This design is important because it is the only way for the user to access web-based service registries in landline environments. The service information exchanged follows a ridge format that is also shown in FIG. 2.
The overall service information 22 has been labeled service book 30 for ease of reference. The use of UDDI to define the form of a service book 30 is present only for illustration. UDDI is well known and is currently defined as a note in the W3C. However, there are many other formats, definitions and proprietary methods to define a service book 30 that would have a similar functionality. The service book in the UDDI XML schema represents four main XML core types of information. These four information types include business information 22, service information 24, binding information 26 and service specific information 28. These information sections are build in hierarchies and are sub-sections of the layer above it. These types of information groups provide different levels of functionality. The business information section 22 allows top-level searching for company names and company sectors; these are often called ‘white pages’. Different taxonomies are provided to find companies that service a specific industry or who are located in a given region of the country; these are often called ‘yellow pages’. Further within the business information section 22 are sub-sections for defining service information 24, binding information 26 and detailed service information 28; these are often called ‘green pages’. Service information 24 includes a grouping to define common services for further categorization. Binding information 26 includes routing information to find the service, either through URI (URL) type references or some other proprietary numbering method. The detailed service information 28 includes capabilities of the service and define elements like security level, data formats, database types, specific data access schemas and many other possible data exchange requirements. There are many other components of the UDDI XML schema but for this description these sections indicate a possible definition for a service book 30 entity.